A Staged Model for the Software Life Cycle

S oftware engineers have traditionally considered any work after initial delivery as simply software maintenance. Some researchers have divided this work into various tasks, including making changes to functionality (perfec-tive), changing the environment (adaptive), correcting errors (corrective), and making improvements to avoid future problems (preventive), 1 but still most have considered maintenance basically uniform over time. Because software development has changed considerably since its early days, this approach no longer suffices. We describe a new view of the software life cycle in which maintenance is actually a series of distinct stages, each with different activities, tools, and business consequences. Both business and engineering can benefit from understanding these stages and their transitions. As Figure 1 shows, according to our model, the software life cycle consists of five distinct stages: • Initial development. Engineers develop the sys-tem's first functioning version. • Evolution. Engineers extend the capabilities and functionality of the system to meet user needs, possibly in major ways. • Servicing. Engineers make minor defect repairs and simple functional changes. • Phaseout. The company decides not to undertake any more servicing, seeking to generate revenue from the system as long as possible. • Closedown. The company withdraws the system from the market and directs users to a replacement system, if one exists. A variation of this process is the versioned staged model, shown in Figure 2, the backbone of which is the evolution stage. At certain intervals, a company completes a version of its software and releases it to customers. Evolution continues, with the company eventually releasing another version and only servicing the previous version. Many companies use a naming scheme like ..—for example, MSDOS Version 6 Release 22—for this process. The version refers to strategic changes during evolution, and the release refers to servicing patches. Our work has been influenced by Franz Lehner, 2 who provided empirical evidence that activities and their frequency change during a system's life cycle. Manny Lehman 3 documented the inevitability of the evolution stage, demonstrating increases in size, complexity , and functionality during evolution. At first glance we seem to be simply reinventing the waterfall life cycle model. However, the waterfall model calls for the completion of technical deliverables at the end of each stage, which is widely considered impractical. 4 We propose making iterations, but in our model of software change and evolution, the iterations are very different in the early and late stages …